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Date: 7 Apr 1994 22:43:55 -0700
From: network.ucsd.edu!not-for-mail@network.ucsd.edu
Subject: BBS-to-Internet address transformations
To: packet-radio@ucsd.edu

[Some of you (well, Hank, anyway) seem to have missed this proposal the first
time around.  Here it is again.]

Any hambbs-to-internet gateway which forwards mail will be required to

	1) be fully registered (both A and MX records) with
	the AMPR.ORG domain server.

	2) be able to utilize MX records for mail exchange on the
	internet.

	3) be capable of accomodating a routing table large enough to
	handle all the ham packet BBSs that will be routing to the
	internet through it, and automatically update that table.

	4) be able to generate MX records as required and submit them to
	the central ampr.org database maintenance robot, either
	automatically or by hand.

The procedure is:

   When mail arrives from an AX.25 bbs at a ham-to-internet gateway
system, the gateway

	1) updates its routing table for that BBS to reflect the routing
	hints contained in the return address.
	E.g., mail arriving at the WB6KDT gateway

		FROM WB6XYZ@WB6CYT.#SOCA.CA.USA.NOAM

	generates a routing table entry of

		WB6CYT			#SOCA.CA.USA.NOAM
	(or whatever the gateway needs to know to reach the bbs via packet)


	2) the bbs from line is rewritten* as

		From: WB6XYZ@WB6CYT.AMPR.ORG

	and the mail is injected into the internet


	3) An MX record for WB6CYT.AMPR.ORG is established (if it does
	not already exist)**, pointing to the gateway system (in this
	example, WB6KDT.AMPR.ORG) with a preference value equal to the
	number of stations the message took to make it to the gateway
	from the bbs where it originated.

Yes, it's a bit elaborate.  But it's RIGHT.  It's clearly the way it
ought to be done.  Let's do it.
	- Brian

* Yes, rewriting addresses is supposed to be a sin.  It's unavoidable
when you change addressing methods between networks, so in this case
we have to do it.  I don't like that either but there's no choice.

** Yes, there's a timing problem here if a reply message is sent
before the nameserver gets updated and propagated.  It's a one-time
problem, though, and could be solved by pre-registration.  After all,
how many BBSs are there near each gateway system?
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